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DETERMINING QUALITY OP SERVICE (QoS) ROOTING 

FOR mobiij: ad hoc networks 

Field of the Invention 
The present invention relates to the field of 
communication networks, and, more particularly, to mobile ad 
hoc wireless networks and related methods. 

Baekground of the Invention 
Wireless networks have experienced increased 
development in the past decade. One of the most rapidly 
developing areas is mobile ad hoc networks. Physically, a 
mobile ad hoc network includes a number of geographically- 
distributed, potentially mobile nodes sharing a common radio 
channel. Compared with other type of networks, such as 
cellular networks or satellite networks, the most distinctive 
feature of mobile ad hoc networks is the lack of any fixed 
infrastructure. The network is formed of mobile nodes only, 
and a network is created on the fly as the nodes transmit with 
each other. The network does not depend on a particular node 
and dynamically adjusts as some nodes join or others leave the 
network . 

In a hostile environment where a fixed communication 
infrastructure is unreliable or unavailable, such as in a 
battle field or in a natural disaster area struck by 
earthquake or hurricane, an ad hoc network can be quickly 
deployed and provide limited but much needed communications. 
While the military is still a major driving force behind the 
development of these networks, ad hoc networks are quickly 
finding new applications in civilian or commercial areas. Ad 
hoc networks will allow people to exchange data in the field 
or in a class room without using any network structure except 
the one they create by simply turning on their computers or 
PDAs. 
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' As wireless communication increasingly permeat:es 
everyday life, new applications for mobile ad hoc networks 
will continue to emerge and become an important part of the 
communication structure. Mobile ad hoc networks pose serious 

5 challenges to the designers. Due to the lack of a fixed 

infrastructure, nodes must self -organize and reconfigure as 
they move, join or leave the network. All nodes are 
essentially the same and there is no natural hierarchy or 
central controller in the network. All functions have to be 

10 distributed ampng the nodes. Nodes are often powered by 
batteries and have limited communication and coir^putation 
capabilities. The bandwidth of the system is usually limited. 
The distance between two nodes often exceeds the radio 
transmission range, and a transmission has to be relayed by 

15 other nodes before reaching its destination. Consequently, a 
network has a multihop topology, and this topology changes as 
the nodes move around. 

The Mobile Ad-Hoc Networks (MANET) working group of 
the Internet Engineering Task Force (IETF) has been actively 

20 evaluating and standardizing routing, including multicasting, 
protocols. Because the network topology changes arbitrarily as 
the nodes move, information is subject to becoming obsolete, 
and different nodes often have different views of the network, 
both in time (information may be outdated at some nodes but 

25 current at others) and in space (a node may only know the 
network topology in its neighborhood and not far away from 
itself) . 

A routing protocol needs to adapt to frequent 
topology changes and with less accurate information. Because 
30 of these unicpie requirements, routing in these networks are 

very different from others. Gathering fresh information about 
the entire network is often costly and impractical. Many 
routing protocols are reactive (on-demand) protocols: they 
collect routing information only when necessary and to 
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destinations they need routes to, and do not maintain unused " 
routes. This way the routing overhead is greatly reduced 
conipared to pro-active protocols which naintain optical routes 
to all destinations at all time. This is important for a 
5 protocol to be adaptive. Ad Hoc on Demand Distance Vector 
(AODV) , Dynamic Source Routing (DSR) and Temporally Ordered 
Routing Algorithm (TORA) are representatives of on-demand 
routing protocols presented at the MANET working group. 

Examples of other various routing protocols include 
10 Destination Sequenced Distance-Vector (DSDV) routing which is 
disclosed in D.S. Patent No. 5,412,654 to Perkins, and Zone 
Routing Protocol (ZRP) which is disclosed in D.S. Patent No 
6,304,556 to Haas. ZRP is a hybrid protocol using both 
proactive and reactive approaches. 

"^^^^^ conventional routing protocols use a best 
effort approach in selecting a route from the source node to 
the destination node. Typically, the number of hops is the 
main criteria in such a best effort approach. m other words, 
the route with the least amount of hops is selected as the 
20 transmission route. 

Quality-of -service (QoS) routing in mobile ad hoc 
networks is gaining interest. To provide quality-of -service, 
the protocol needs not only to find a route but also to secure 
the resources along the route. Because of the limited, shared 
bandwidth Of the network, and lack of central controller which 
can account for and control these limited resources, nodes 
must negotiate with each other to manage the resources 
required for QoS routes. This is further con^^licated by 
frequent topology changes. Due to these constraints, QoS 
routing is more demanding than best-effort routing. 

Some examples of QoS routing approaches are set 
forth by Chenxi Zhu in the publication entitled "Medium Access 
Control and Quality-of-Service Routing for Mobile Ad Hoc 
Networks," 2001, and by M. Mirhakkak et al. in the publication 
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entitled ^^Dynaitdc Quality-of-Service for Mobile Ad Hoc 
Networks MITRE Corp., 2000. Zhu discusses establishing 
bandwidth guaranteed QoS routes in small networks whose 
topologies change at a low to medium rate. Mirhakkak et al. 

5 are concerned with resource reservation requests which specify 
a range of QoS values while the network makes a commitment to 
provide service within this range. 

At each node, admission control is performed to 
forward traffic from other nodes. Typically, conventional 

10 admission control protocols provide for full. disclosure 

regarding routes and connectivity. In other words, each node 
shares all route and connectivity data with other nodes so 
that the best-effort routes are selected overall. 

15 Summary of the Invention 

In view of the foregoing background, it is therefore 
an object of the present invention to provide route 
determination for multihop routes in a mobile ad hoc network 
that ensure quality of service constraints. 

20 This and other objects, features, and advantages in 

accordance with the present invention are provided by a method 
for determining a route from a source node to a destination 
node in a mobile ad hoc network- The network including a 
plurality of mobile nodes including the source node and the 

25 destination node with intermediate nodes therebetween. The 

method including transmitting a quality-of-service (QoS) route 
request from the source node to discover routing to the 
destination node based upon a QoS parameter, and the route 
request including a flow identifier and a QoS link metric. 

30 Furthermore, the method includes each intermediate node 

determining whether the node can support the requested QoS 
parameter of the QoS route request and, if so, updating the 
QoS link metrics, forwarding the QoS route request to one of 
other inteonnediate nodes and the destination node, and 



-4- 



wo 03/093926 



PCT/US03/1314I 



10 



30 



temporarily reserving node resources for QoS route requests 
having supportable QoS parameters. The destination node, upon 
receiving the QoS route request, generates a reply to the 
source node including the flow identifier and updated QoS link 
metrics for each discovered route, and the source node 
generates QoS route or path metrics based upon updated QoS 
link metrics in replies from the destination nodes for 
discovered routes. Route replies do not necessarily have to 
return to the source via the same path as the route requests. 
Also, the source node selects a route to the destination node 
based upon the QoS route metrics, and the source node 
transmits route confirmations to intermediate nodes on the 
selected route. 

The QoS parameter preferably comprises a requirement 
15 based upon at least one of available bandwidth, error rate, 
end-to-end delay, end-to-end delay variation, hop count, 
expected path durability, and priority. Also, the source node 
may select at least one standby route either with or without 
sending confirmations to the intermediate nodes on the standby 
route. Confirmations sent over a standby route will insure 
that the route is maintained by all intermediate nodes and 
that resources will continue to be reserved. Any standby 
route for which neither confirmations nor traffic is sent is 
subject to loss of reservation. Such a standby route may also 
be used for duplicate transmissions. Duplicate transmissions 
along the standby path may be used for providing reliability 
of data transmission or for enabling a less disruptive 
handover to the standby path when a failure occurs along the 
primary path. A standby path can also be kept alive by 
transmitting periodic confirmations along the path also to 
enable a less disruptive handover to the standby path when a 
failure occurs along the primary path. At any time, the 
intermediate nodes and the destination node may detect whether 
the node can continue to support the requested QoS parameter 

-5- 
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of the QoS route request and, if not, generate a QoS error 
notification to the source node. Also, the source node may 
maintain the selected route, upon receiving the QoS error 
notification, while transmitting a second quality-of-service 

5 (QoS) route request to discover new routing to the destination 
node based upon the QoS paraoneter, 

The source node may also select a standby route and 
switch to the standby route upon receiving the QoS error 
notification. The source node may also send confirmations to 

10 . the intermediate nodes on the standby route. 

A system aspect of the invention is directed to a 
mobile ad hoc network including a plurality of mobile nodes, 
and a plurality of wireless communication links connecting the 
plurality of mobile nodes together. Each mobile node includes 

15 a communications device to wirelessly and either 

unidirectionally or bi-directionally communicate with other 
nodes of the plurality of nodes via the wireless communication 
links, and a controller to route communications via the 
communications device. The controller includes a route 

20 discovery unit to transmit quality-of-service (QoS) route 

requests to other nodes to discover routing to a destination 
node based upon at least one QoS parameter, and the route 
request includes a flow identifier and a QoS link metric. 
Also, a route request processing unit determines whether the 

25 node can support a requested QoS parameter of a QoS route 
request and to update the QoS link metric, and a temporary 
resource reservation table contains temporary node resource 
reservations for QoS route requests having supportable QoS 
parameters. Furthermore, a route metric formation unit 

30 generates QoS route metrics based upon updated QoS link 

metrics in replies from nodes with node resource reservations, 
and a route selection unit selects a route to the destination 
node based upon the QoS route metrics and to transmit route 
confirmations to nodes on a selected route. 
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Brief Descrip tion of the Drawine^s 
FIGS. 1-4 are schematic diagrams of a mobile ad hoc 
network including QoS routing in accordance with the present 
invention . 

5 FIG. 5 is a flowchart illustrating the method steps 

for QOS routing in a mobile ad hoc network in accordance with 
the present invention. 

FIG. 6 is a schematic diagram illustrating a router 
of a node in accordance with the network of the present 
10 invention . 

PIG. 7 is a schematic diagram illustrating the 
details of the controller of the router in FIG. 6. 

FIGS. 8-10 are schematic diagrams of a mobile ad hoc 
network including admission control in accordance with the 
15 present invention. 

FIG. 11 is a flowchart illustrating the method steps 
for admission control in a mobile ad hoc network in accordance 
with the present invention. 

PIG. 12 is a flowchart illustrating the method steps 
for policing traffic admission control in a mobile ad hoc 
network in accordance with the present invention. 

FIG. 13 is a schematic diagram of a mobile ad hoc 
network including traffic tracking in accordance with the 
present invention. 

FIG. 14 is a flowchart illustrating the method steps 
for tracking traffic in a mobile ad hoc network in accordance 
with the present invention. 

FIGS. 15-17 are schematic diagrams of a mobile ad 
hoc network including dynamic channel allocation in accordance 
with the present invention. 

FIG. 18 is a flowchart illustrating the method steps 
for dynamic channel allocation in a mobile ad hoc network in 
accordance with the present invention. 
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Detailed Description of the Preferred Embodimente 

The present invention will now be described more 
fully hereinafter with reference to the accompanying drawings, 
. in which preferred embodiments of the invention are shown. 

5 This invention may, however, be embodied in many different 
forms and should not be construed as limited to the 
embodiments set forth herein. Rather, these embodiments are 
provided so that this disclosure will be thorough and 
complete, and will fully convey the scope of the invention to 

10 those skilled in the art. Like numbers refer to like elements 
throughout, and prime notation is used to indicate similar 
elements in alternative embodiments. 

As will be appreciated by those skilled in the art, 
portions of the present invention may be embodied as a method, 

15 data processing system, or computer program product. 

Accordingly, these portions of the present invention may take 
the form of an entirely hardware embodiment, an entirely 
software embodiment, or an embodiment combining software and 
hardware aspects. Furthermore, portions of the present 

20 invention may be a computer program product on a conqputer- 

usable storage medium having computer readable program code on 
the medium. Any suitable computer readeUDle medium may be 
utilized including, but not limited to, static and dynamic 
storage devices, hard disks, optical storage devices, and 

25 magnetic storage devices. 

The present invention is described below with 
reference to flowchart illustrations of methods, systems, and 
computer program products according to an embodiment of the 
invention. It will be understood that blocks of the 

30 illustrations, and combinations of blocks in the 

illustrations, can be implemented by computer program 
instructions. These computer program instructions may be 
provided to a processor of a general purpose computer, special 
purpose computer, or other programmable data processing 
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apparatus to produce a machine, such that the instructions, 
which execute via the processor of the computer or other 
prograramable data processing apparatus, implement the 
functions specified in the block or blocks. 

These computer program instructions may also be 
stored in a computer-readable memory that can direct a 
computer or other programmable data processing apparatus to 
function in a particular manner, such that the instructions 
stored in the computer-readable memory result in an article of 
manufacture including instructions which implement the 
function specified in the flowchart block or blocks. The 
computer program instructions may also be loaded onto a 
computer or other programmable data processing apparatus to 
cause a series of operational steps to be performed on the 
computer or other programmable apparatus to produce a computer 
implemented process such that the instructions which execute 
on the computer or other programmable apparatus provide steps 
for implementing the functions specified in the flowchart 
block or blocks. 

Referring initially to PIGs. 1-5, a method for 
determining a route from a source node to a destination node 
in a mobile ad hoc network 20 will now be described. The 
network 20 includes a plurality of mobile nodes 30 including 
the source node 1 and the destination node 4 with intermediate 
nodes 2, 3 and 5 therebetween. The nodes 30, such as laptop 
coa^jutera, personal digital assistants (PDAs) or mobile 
phones, are connected by wireless communication links 32 as 
would be appreciated by the skilled artisan. The method begins 
(block 100) and includes transmitting a quality-of-service 
(QoS) route request RREQQ from the source node X to discover 
routing to the destination node 4 based upon a QoS parameter, 
as indicated at block 102 in FIG. 5. The QoS parameter is 
preferably based upon available bandwidth, error rate, end-to- 
end delay, end-to-end delay variation, hop count, expected 
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path durability/ and/or priority as will be discussed in 
further detail below. The route request RREQQ includes a QOS 
flow identifier and an updatable QoS link metric. 

Furthermore, at block 104, the method includes each 
intermediate node 2, 3 and 5 determining whether the node can 
support the requested QoS parameter of the QoS route request 
RREQQ. If the node cannot support the QoS parameter of a 
particular request RREQQ, then the request is denied or simply 
not forwarded by the node (block 106) • If the node, for 
example node 3, can support the QoS parameter of a particular 
request RREQQ, then the node updates the QoS link metric, 
forwards the QoS route request to other intermediate nodes 2 
and 5, and temiporarily reserves node resources for that QoS 
route request (block 108) • Intermediate nodes 2 and 5 also 
must determine whether they can support the requested QoS 
parameter of the QoS route request RREQQ forwarded from node 
3. If so, the route request RREQQ with the updated QoS link 
metric is then forwarded to the destination node 4, 

The destination node 4, upon receiving the QoS route 
request RREQQ, generates a reply RREPQ to the source node 1 
including the flow identifier and updated QoS link metric for 
each discovered route (block 110) • In other words, the 
destination node 4 may have received the forwarded route 
request RREQQ from any of various possible routes including, 
for example, 1-2-4 or 1-3-5-4. A reply RREPQ is generated in 
each case. At block 112, the source node 1 generates QoS route 
metrics based upon updated QoS link metrics in replies RREPQ 
from the destination node 4 for discovered routes. Also, at 
block 114, the source node 1' then selects a route to the 
destination node 4 based upon the QoS route metrics, and, at 
block 116, the source node transmits route confirmations CONFQ 
to intermediate nodes on the selected route. This is to 
confirm the use of the resources on the selected route that 
were temporarily reserved at block 108. Other temporarily 

-10- 
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reserved resources on discovered but non-selected routes may 
be permitted to time out by not transmitting CONFQ on those 
routes . 

Also, the source node I may select at least one 
standby route either with or without sending confirmations 
CONFQ to the intermediate nodes on the standby route (block 
122) . Such a standby route may be for duplicate transmissions, 
for additional reliability, or may be used as a backup route 
in case of route and/or QoS failure. At block 118, the 
intermediate nodes 2, 3 and 5, and/or the destination node 4, 
may detect at any time whether the node can continue to 
support the requested QoS parameter of the QoS route request 
RREQQ. If the node can continue to support the request rreqq 
throughout propagation of the traffic, reserved resources and 
associated routes may be permitted to time out if determined 
inactive, at block 126, and be released, block 128, if not 
used for a period of time either by data traffic or by the 
sending of periodic CONFQ messages. 

If the node cannot continue to support the request 
RREQQ, then the node generates a QoS error notification RERRQ 
to the source node 1 (block 120) . Here, the source node 1 may 
maintain the selected route, upon receiving the QoS error 
notification RERRQ, while again transmitting a quality-of- 
service (QoS) route request RREQQ to discover a new routing 
25 path to the destination node 4 based upon the QoS parameter 

(block 102) . The source node 1 may also switch to the standby 
route upon receiving the QoS error notification rerrq (block 
124) . 

The described method can be applied to any type of 
On-Demand or Reactive routing protocol, such as Dynamic Source 
Routing (DSR) or Ad-Hoc On-Demand Distance Vector (AODV) 
routing, or to any hybrid proactive/reactive protocol, such as 
Zone Routing Protocol (2RP), as would be appreciated by the 
skilled artisan. 
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A more specific example considering xainiinum 
bandwidth allocation and a maximum delay constraint as 
categories of QoS will now be described. For a fixed bandwidth 
allocation it is assumed that a node 30 is able to reserve a 

5 certain amount of capacity or bandwidth. Again, source node 1 
of a traffic flow will send the QoS Route Request RREQQ for 
each required flow (the last Q in the notation indicates a QoS 
request) . The RREQQ message performs the function of 
discovering a route that can support the required QoS. Nodes 

10 that forward the RREQQ to the destination 4 will note if they 
can meet the requested QoS before passing on the RREQQ and 
they will temporarily reserve resources if needed. A Route 
Reply RREPQ packet is returned from the destination with an 
indication that the requested QoS can be met over that path. 

15 The source node 1 may then collect multiple potential paths to 
the destination 4 before deciding upon the best choice to 
provide the desired QoS. Once this path is determined, a 
Confirm CONFQ message is sent to the destination 4 along the 
indicated path. Along the way on this path any temporary 

20 resource reservations are confirmed to be permanent 

reservations. QoS reservations are timed out if not used for a 
specified period of time. If a link fails along the route or 
if the QoS requirement cannot be met, a Route Error (RERRQ) 
packet is generated and returned to the source node. 

25 More specifically, when a new QoS route is needed to 

a given destination node 4, the source node 1 broadcasts a 
RREQQ packet to the destination node. This is a special type 
of packet similar to the conventional RREQ packet used in a 
protocol such as DSR or AODV. The conventional RREQ broadcast 

30 is used for ^best effort" service. The method of the present 
invention may still follow the conventional procedures 
established by the protocol for best effort service. 

If a specified minimum capacity or bandwidth is 
required for a traffic flow, the special RREQQ packet is used 
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to reserve a flow at a specified capacity to the destination 
4. In this case, a flow ID is assigned to the RREQQ by the 
source node 1 which combined, with the source node address 
uniquely identifies the flow to any node in the network 20 
5 that is forwarding the flow. The RREQQ packet also indicates 
the capacity that is to be reserved. 

At each node 2, 3 and 5 in the path to the 
destination 4, the minimum capacity or bandwidth requirement 
is checked against available capacity to determine if a 
10 reservation can be made for the flow. If the node can 

accommodate the required traffic flow, then the capacity is 
temporarily reserved for that flow ID, This temporary 
reservation is released if a CONFQ message is not received 
within a short period of time. If the RREQQ is meant to insure 
15 that a path can be found that does not exceed a specified 

maximum delay, then each node along the path must be able to 
estimate its contribution to the total path delay and check to 
see if the total delay along the path so far plus its 
contribution exceeds the specified maximum delay bound. 

Unlike conventional application of DSR and AODV for 
*"best effort" traffic, the RREQQ must be allowed to propagate 
all the way to the destination node 4 to determine if a valid 
path exists that satisfies the QoS requirement. If such a path 
is founds then the destination node 4 generates a RREPQ 
25 message to be returned to the source node 1. This message 

indicates to the source node that a valid path has been found 
to the destination node 4 that satisfies the requested QoS and 
a route has been established (in the case of DSR a source 
route is returned) . Estimated path delay is included in the 
30 RREPQ for a request seeking a delay guarantee as well as for a 
path guaranteeing capacity. 

The source node 1 may receive multiple RREPQ for 
paths to the destination node 4 that can meet the required 
QoS . It will rank order these and send out a CONFQ message 

-13" 
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indicating its selection of a path on the highest ranked path. 
The other paths may be kept as backup paths , but if the CONFQ 
is not sent on these paths, there is no guarantee that the 
required resources will be available if needed as a backup 

5 alternate path. 

If at any intermediate node 2, 3 and 5 or the 
destination node 4, the requested QoS is violated and cannot 
be satisfied, then the RREQQ packet is discarded knowing that 
the path through this node cannot satisfy the requested QoS. 

10 However r other paths may be found by the discovery process. If 
at any time a link fails along the route or if the QoS 
requirement cannot be* met, a Route Error RERRQ packet is 
generated and returned to the source node 1 for each traffic 
flow affected by the failure. In this case either a backup 

15 path must be used or the route discovery process is initiated 
again. 

The described procedures are easily applied to the 
DSR protocol. The conventional DSR message types RREQ, RREP, 
RRER are defined as optional packet types, and can be used as 

20 defined for the conventional operation of the protocol to 
support *^best effort" traffic in a backwards compatibility 
mode. New optional packet types are defined to support QoS 
including the RREQQ, RREPQ, RRERQ, and CONFQ packet types to 
be used for managing QoS paths. Definition of the required 

25 header fiislds for these types is straightforward based on the 
functions defined above. A special type of QoS source routed 
packet for QoS mission data would also be included. This 
packet would include the flow ID to identify which flow the 
packet belonged and to allow for metering of flow traffic. 

30 The following procedures would be used if a failure 

causes a node to issue a RERRQ packet. If a RERRQ packet is 
received at the source node, then the current route is 
discarded and a backup route is tried. The first packet sent 
on the backup route will be another type of special QoS source 
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routed packet, the RREQT, that includes the flow id and the 
QoS parameters. This packet could also include mission data. 
Each node along the path will have to check to see if they are 
still maintaining a temporary reservation for the flow. If not 
5 they will recheck to see if they can support the flow ahd make 
a temporary reservation. If the packet reaches the destination 
with the flow supported at each intermediate node, then the 
destination node will return a RREPQ packet notifying the 
source that the path is valid. 

If any node cannot support the flow, then the packet 
is discarded and the node returns a RERRQ packet to the source 
node notifying it that the path cannot support the requested 
QoS parameters. If the source node receives a RREPQ packet, 
then it sends a CONFQ message along the selected path 
15 confirming the choice of path in addition to continuing to 
send the mission data for that traffic flow. 

If the source node receives a RERRQ packet, then it 
tries the same procedure on the next available backup path, 'if 
the source node has no more backup source routes to the 
destination, the source node begins another route discovery 
process for a new QoS path to the destination node. Mission 
data flow is interrupted until a new route is found. For any 
specific protocol, the data structures required to manage the 
resources allocated to each traffic flow can be defined, and 
how to identify the flows and how to look up the routes 
assigned to each flow can also be defined. 

Referring now additionally to Figs. 6 and 7, a 
system aspect of the invention will be described. A mobile ad 
hoc network 20 includes a plurality of mobile nodes 30, and a 
plurality of wireless communication links 32 connecting the 
plurality of mobile nodes together. Each mobile node includes 
a router 40 (FIG. 6) that has a communications device 42 to 
wirelessly and uni-directionally or bi-directionally 
communicate with other nodes via the wireless communication 
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links 32, and a controller 44 to route coiranunications via the 
communications device 42. Also, a memory 46 may be included as 
part of the controller 44 or in connection with the 
controller. 

5 As shown in FIG, 1, the controller 44 includes a 

route discovery unit 50 to transmit the quality-of-service 
(QoS) route requests to other nodes to discover routing to a 
destination node based upon at least one QoS parameter. Again, 
the route request includes a flow identifier and a QoS link 

10. metric. Also, a route request processing, unit 52 determines 
whether the node can support a requested QoS parameter of a 
QoS route request and to update the QoS link metric, and a 
temporary resource reservation table 54 contains temporary 
node resource reservations for QoS route requests having 

15 supportable QoS parameters- Furthermore, a route metric 
formation unit 56 generates QoS route metrics based upon 
updated QoS link metrics in replies from nodes with node 
resource reservations, and a route selection unit 58 selects a 
route to the destination node based upon the QoS route metrics 

20 and to transmit route confirmations to nodes on a selected 
route . 

The route selection unit 58 may select a standby 
route, such as for backup or duplicate transmissions, with or 
without sending confirmations CONFQ to the nodes on the 

25 standby route. The route request processing unit 52 detects 
whether the node can continue to support the requested QoS 
parameter of the QoS route request and, if not, generates the 
QoS error notification RBRRQ. The route selection unit 58 
preferably maintains the selected route, upon receiving a QoS 

30 error notification from another node, while the route 

discovery unit 50 transmits another quality-of -service (QoS) 
route request RREQQ to discover new routing to the destination 
node based upon the QoS parameter. The route selection unit 58 
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may switch to the standby route upon receiving the QoS error 
notification RERRQ from another node. 

Another embodiment of the present invention provides 
traffic admission control for multihop routes in the mobile ad 
hoc network 22 while maintaining the quality of service 
needed, and will be described with reference to FIGs. 8-11. 
Such an admission control method will adaptively allow a node 
to keep some resources for its own traffic, while sharing 
fairly in the forwarding of other's traffic. Again, the ad- 
hoc network is made up of a plurality of wireless mobile nodes 
30 and a plurality of wireless communication links 32 
connecting the plurality of nodes together. 

The method for controlling traffic admission in the 
mobile ad hoc network 22 begins (block 200) and includes a 
source node transmitting qfuality-of -service (QoS) route 
requests RREQQ to discover traffic routing based upon a QoS 
parameter (block 202). At block 208, each node 30 in the 
network 22 calculates a node QoS tag value to make traffic 
admission control decisions. The node QoS tag value is a 
function of at least one node specific QoS metric. The QoS 
parameter may be based upon, for example, bandwidth, error 
rate, end-to-end delay, end-to-end delay variation, hop count, 
expected path durability, and/or priority, while the node 
specific QoS metric may include one or more of available 
power, available bandwidth by the node, recent error rate, 
recent delay, available bandwidth by other nodes within a' 
range, and node queue size, for example. The QoS tag value may 
be a weighted sum of each term, or a vector with each term as 
an element. 

Each node 30 determines admission based upon the 
calculated QoS tag value and the QoS parameter of QoS route 
requests RREQQ, and may reply to the source node, regarding 
Whether traffic will be admitted in response to the QoS route 
requests (block 214) . Furthermore, each node 30 may calculate 
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route and connectivity information associated with the node 
(block 210) , and transmit the route and connectivity 
information and the QoS tag value to other nodes for traffic 
route selection (block 212) . 

5 Calculating the node QoS tag value 208 may include 

querying other nodes within a range for information regarding 
at least one QoS metric (block 204), and processing the QoS 
metric information received from the other nodes and the at 
least one node specific QoS metric to calculate the node QoS 

10 tag value. Calculating the node QoS tag value may further 

comprise verifying that each other node within the range has 
replied with QoS metric information (block 206) . 

More specifically^ most of the QoS metric terms such 
as available power, available bandwidth by the node, recent 

15 error rate, recent delay, and node queue size, are known 

locally to the node. However, available bandwidth by other 
nodes within a range, for example, is not known locally. Thus, 
referring to FIG. 8, if node 1 issues a request to node 4 for 
5 Mbps of an 11 Mbps transmission medium, node 4 must check to 

20 see if any other nodes in range (here nodes 1, 3 and 5) have 
already made prohibitive commitments. So, node 4 broadcasts a 
CHECK message and any nodes within range that have committed 
bandwidth will send a CHECK REPLY back indicating such. Node 4 
makes sure that it has heard a CHECK REPLY from all nodes that 

25 it has heard from lately. With the received information, node 
4 can now make a decision on whether it can support the QoS 
parameter of the route request RREQQ. 

Replying to QoS route requests (block 214) may 
comprise indicating what traffic routing the node can support 

30 based upon the node QoS tag value, when the node cannot 

support the QoS parameter of the route request. For example, 
if node 4 cannot commit to the reG[uest, it may issue a reply 
that describes the most that it can support- Accordingly, the 
source can decide whether the level is good enough or whether 
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to scale back the request and issue a relaxed QoS request 
RREQQ. 

As discussed, conventional approaches provide full 
disclosure regarding routes and connectivity. in other words, 
each node 30 shares all that it knows with others, so that 
"best" (usually fewest hops) routes are selected overall m 
this invention, this route and connectivity information is 
tagged with a value that allows other nodes to use it based on 
the Quality of Service needed. Additionally, the node sharing 
the information can decide on the level of QoS that will be 
allowed to use that information. This decision can be based on 
a common set of rules, or per node since some nodes will be 
advantaged. For example, a node that finds itself forwarding 
many packets, whose battery is running out, and is having 
trouble finding bandwidth for its own traffic may advertise 
has routes and connectivity to certain other nodes with a tag 
that disallows all but the most important (high priority) 
packets . 

A system aspect of this embodiment of the present 
invention is directed to the mobile ad hoc network 22 
including the plursdity of mobile nodes 30, and the plurality 
of wireless communication links 32 connecting the plurality of 
mobile nodes together. As described earlier with reference to 
FIGS. 6 and 7, each mobile node has a router 40 that includes 
the communications device 42 to wirelessly and 
unidirectionally or bi-directionally communicate with other 
via the wireless communication links, and a controller 44 to 
route communications via the communications device. The 
controller 44 includes a route discovery unit 50 to transmit 
quality-of -service (QoS) route requests to other nodes to 
discover routing to a destination node based upon at least one 
QOS parameter. Here, a QoS tag calculation unit 60 calculates ' 
the node QoS tag value to make traffic admission control 
decisions. A traffic admission controller 62 determines 
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whether to admit traffic in response to QoS route requests 
based upon the calculated QoS tag value and the QoS parameter 
of QoS route requests. 

The controller 44 may also include a connectivity 
5 calculator 64 to calculate route and connectivity information 
associated with the node, which may be transmitted to other 
nodes for traffic route selection. The QoS tag calculation 
unit 60 may query other nodes within a range for information 
regarding at least one QoS metric, and process the QoS metric 
10 information received from the other nodes and the at least one 
node specific QoS metric to calculate the node QoS tag value. 
Also, the QoS tag calculation unit 60 may verify that each 
other node within the range has replied with QoS metric 
information • 

15 Furthermore, the route request processing unit 52 

replies to QoS route requests to indicate whether the node can 
support the QoS parameter of the route request and admit the 
traffic. Also, the route recjuest processing unit 52 may 
indicate what traffic routing the node can support based upon 

20 the node QoS tag value, when the node cannot support the* QoS 
parameter of the route request. 

Another embodiment of the present invention provides 
traffic policing for multihop routes in a mobile ad hoc 
network 22, and will be described with reference to FIG. 12. 

25 as previously described, the network 22 includes the plurality 
of wireless mobile nodes 30 and the plurality of wireless 
communication links 32 connecting the plurality of nodes 
together. The method begins at block 300 and includes nodes 
transmitting quality-of -service (QoS) route requests RREQQ to 

30 discover traffic routing based upon a QoS parameter (block 
302) as described in the other embodiments. Here, the QoS 
route reG[uests RREQQ include at least the traffic flow 
identifier. At block 304, each node calculates a node QoS tag 
value to make traffic admission control decisions, and each 
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node determines whether to admit traffic in response to QoS 
route requests based upon the calculated QoS tag value and the 
QoS parameter of QoS route requests (block 306) . Also, at 
block 308, each node replies to QoS route requests to indicate 
5 whether the node can support the QoS parameter of the route 
request and admit the traffic. However, in this embodiment, 
each node polices admitted traffic based upon the traffic flow 
identifier to ensure that admitted traffic does not exceed the 
QoS parameter of the QoS route request RREQQ (block 310) . 

Again, the QoS parameter may be based upon available 
bandwidth, error rate, end-to-end delay, end-to-end delay* 
variation, hop count, expected path durability, and/or 
priority, for example, while the node specific QoS tag value 
may he a function of at least one of available power, 
15 available bandwidth by the node, recent error rate, recent 

delay, available bandwidth by other nodes within a range, and 
node queue size, for example. In other words, if a request 
RREQQ includes a requirement for certain amount of bandwidth, 
for example, and the node admits the traffic associated with 
20 the request, then the node polices itself to ensure that the 
admitted traffic does not exceed the requested bandwidth. 

The method preferably includes each node preventing 
propagation of traffic that exceeds the QoS parameter of the 
QoS route request (block 312) . This step may include 
25 buffering traffic that exceeds the QoS parameter of the QoS 
route request, and propagating buffered traffic at the QoS 
parameter of the QoS route request. Alternatively, each node 
may propagate buffered traffic when required resources become 
available, or simply discard traffic that exceeds the QoS 
30 parameter of the QoS route request. Furthermore, as described 
in the other embodiments, replying to QoS route requests may 
comprise indicating what traffic routing the node can support 
based upon the node QoS tag value, when the node cannot 
support the QoS parameter of the route request, 
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Referring again to FIG- 1, the controller 44 
includes a traffic policing unit 84 to police the admitted 
traffic based upon the traffic flow identifier to ensure that 
admitted traffic does not exceed the QoS parameter of the QoS 
5 route request. Also, the traffic policing unit 84 preferably 
includes an excess traffic buffer 86 for storing the excess 
traffic. 

More specifically, the traffic flow ID is used in 
route tables and in the QoS packets (both control and data) . 

10 As discussed, this provides an identifier for performing 
admission control . The source node that has obtained a 
reservation for a path of a certain capacity, for example, to 
the destination node can use the flow ID and meter the traffic 
to perform policing of the traffic. This guarantees that it 

15 never admits more than agreed upon capacity for that flow ID. 
In addition, each node in the path to the destination can 
perform policing against the allocated capacity. Of course 
criteria other than the available capacity could be used as a 
criteria for deciding whether to support a given flow request - 

20 For example, a node running low on battery power may not want 
to support a given traffic flow. Then in this case, the RREQQ 
message can be ignored thereby disallowing use of the node as 
a forwarding node for the requested traffic flow. 

Another embodiment of the present invention provides 

25 traffic tracking for multihop routes in a mobile ad hoc 

network, and will be described with reference to FIGs . 13 cuid 
14. As shown in FIG- 13, the network 24 again includes a 
plurality of wireless mobile nodes 30 and a plurality of 
wireless communication links 32 connecting the plurality, of 

30 nodes together. The method begins at block 400 (FIG. 14) and 
includes each node monitoring traffic communicated between 
nodes 30 in the network 24 (block 402). Each node 30 generates 
traffic information based upon how much traffic is being 
communicated between various nodes in the network 24 (block 
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404), and each node stores the traffic information locally in 
a buffer as a traffic database (block 406) . 

In the method, the traffic information is preferably 
based upon bandwidth and may include error rate, end-to-end 
5 delay, end-to-end delay variation, hop count, expected path 
durability, and/or priority. The traffic database may comprise 
a 1-hop traffic matrix. In other words, the database for a 
specific node 1 would include traffic information for each 
link 32 between nodes 2-8 in the network. In FIG. 13, node 1 
10 needs a traffic route A to node 6. Here, if nodes 7 and 8 are 
sending large amounts of traffic, but nodes 1-6 are not, it 
would be better to route traffic through 1-2-3-4-5-6 rather 
than 1-7-8-6 even though it would result in more hops. 

The method may be advantageous to routing protocol 
15 selection, protocol parameter optimization, and route 

selection. A traffic matrix is shown in the example below. For 
a 7 node network, each element in the matrix denotes how much 
traffic, if any, is being sent from the source node on that 
row to the destination node on that column. Here, the traffic 
20 is quantified in terms bandwidth over some interval (recent 
bandwidth used may be weighted more) , and may include packet 
loss rate, delay, etc. If the traffic matrix is sparsely 
populated (lots of zero or near zero bandwidth entries), a 
reactive routing protocol would be more advantageous, since 
25 routes are not constantly updated that will not be used 

anyway. Conversely, a dense traffic matrix would indicate 
lots of interaction between nodes 30 and a proactive or hybrid 
protocol may provide benefits. Accordingly, the method may 
include each node selecting a route discovery protocol, such 
30 as a reactive, proactive or hybrid protocol, based upon the 
stored traffic information and (block 412) . 
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TRAFFIC DATABASE 



Nodes know what traffic they are sending, receiving 
5 and forwarding. To know traffic they are not directly 

involved with, they can monitor or be explicitly sent messages 
containing traffic data. Routing protocols such as DSR that 
collect route information promiscuously (by hearing other 
nodes' requests RREQ and replies RRBP/ or by observing the 
10 source route in data packets) could be adapted to build much 
of the traffic matrix. Link-state routing protocols, such as 
optimized link state routing (OLSR) , already share route 
information, and could be extended to share traffic matrix 
information, since each node knows what it sends to whom, and 
15 at what quality. Also, a protocol could set timers according 
to expected delays through a sequence of hops, based upon the 
traffic matrix bandwidths, since it will know what delays to 
expect due to traffic congestion. This may reduce or 
eliminate unnecessary timeouts from occurring. 

20 
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Furthermore, at block 408, each node 30 may generate 
traffic destination infomation based upon how many 
destinations each of various nodes communicates with in the 
network 24, and store (block 410) the traffic destination 
5 information in a destination quantity database. Thus, each 

node 30 may also discover and select traffic routes based upon 
the stored traffic destination information. In other words, 
the destination quantity database would reveal the number of 
destinations that each of the particular nodes is 
10 communicating with. 

Referring again to FIG. 7, the controller 44 of a 
router 40 in a network 24 in accordance with this embodiment, 
includes a traffic monitoring unit 70 to monitor traffic 
communicated between nodes 30 in the network. A traffic 
information generator 76 generates traffic information based 
upon how much traffic is being communicated between various 
nodes in the network, and a traffic information buffer 78 
stores the traffic information in a traffic database. 

The traffic monitoring unit 70 may broadcast a 
traffic activity query, and processes replies to the traffic 
activity query. Alternatively, the traffic monitoring unit 70 
may passively monitor the traffic between nodes 30 in the 
network 24. The route discovery unit 50 discovers routing to a 
destination node based upon the stored traffic information, 
25 and the route selection unit 58 selects traffic routes to the 
destination node based upon the stored traffic information. 
Also, the route discovery unit 50 may process the traffic 
information stored in the traffic database to select one of a 
reactive, proactive and hybrid route discovery process, and 
discovers traffic routes with the selected route discovery 
process. Bach traffic route comprises a combination of 
wireless communication links 32. 
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A traffic destination information generator 72 
generates traffic destination information based upon how many 
destinations each of various nodes 30 communicates with in the 
network 24, and a destination information buffer 74 stores the 

5 traffic destination information in a destination quantity 
database. The route discovery unit 50 may also discover 
routing to a destination node based upon the stored traffic 
destination information, and the route selection unit 58 may 
select traffic routes to the destination node based upon the 

10 stored traffic destination information. 

Another embodiment of the present invention provides 
dynamic channel allocation in the mobile ad hoc network to 
efficiently make use of a plurality of channels. A method for 
dynamic channel allocation will be described while referring 

15 to FIGs. 15-18. Here, the network 26 includes a plurality of 
wireless mobile nodes 30 and a plurality of wireless 
communication links 32 connecting the plurality of nodes 
together over a plurality of channels. IEEE 802.11 spinoffs 
like 802.11a will make use of the ISM spectrum in the 5 GHz 

20 band. In this band, there is more bandwidth available to 

support many channels. As a result, a process to automatically 
assign a channel to an 802.11 node would be important. Such a 
channel decision would be based on current channel utilization 
and sampling of the other channels. Using dynamic channel 

25 selection would provide better performance since the spectrum 
would be used evenly. Additionally, channel use could be 
throttled such that QoS is maintained for current stations 
using the channel. 

The method begins at block 500 (FIG. 18) and 

30 includes each node 30 monitoring link performance on a first 
channel. Link performance is based upon a quality of service 
(QoS) threshold, such as bandwidth, error rate, end-to-end 
delay, end-to-end delay variation, hop count, expected path 
durability, and priority, for example. At block 504) each node 
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scouts one or more other available channels when the monitored 
link performance on the first channel falls below the QoS 
threshold, for example, minimum bandwidth or maximum delay. 
Scouting may include periodically monitoring other channels 
for link performance. 

Scouting may comprise switching to a second channel 
(block 512) , broadcasting a channel activity query to 
determine the link performance for the second channel (block 
516) , and processing replies to the channel activity query to 
determine the link performance for the second channel at block 
518. Furthermore, each node 30 may switch back to the first 
channel and broadcast a channel change message if the link 
performance on the second channel is above the QoS threshold 
(block 506) , or switch to subsequent channels and broadcast 
channel activity queries to determine the link performance for 
•.the those channels if the link performance on the previous 
channel is below the QoS threshold (block 504) . 

Alternatively, scouting may comprise switching to 
another channel (block 512) , and passively monitoring the link 
performance for the second channel at block 514. Again, each 
node 30 may switch back to the first channel and broadcast a 
channel change message if the link performance on the second 
channel is above the QoS threshold (block 506), or switch to 
subsequent channels and passively monitor the link performance 
25 for those channels if the link performance on the previous 
channel is below the QoS threshold (block 504) . Also, each 
node 30 may store link performance information of each of the 
plurality of channels (block 508) and/or store channel 
information for neighboring nodes at block 510. In other 
words, each node 30 may keep track of what channel other nodes 
are using. 

For example, as shown in FIGs . 15-17, the network 26 
includes nodes 30 and links 32. Nodes 1A-5A are currently 
using a first channel, while nodes IB-SB are currently using a ' 

-27- 



20 



30 



wo 03/093926 



PCTAJS03/1314] 



second channel. Node 2B determines that the link performance 
. for the second channel is falling or has fallen below a QoS 
threshold, such as bislow a lainimum bandwidth. Node 2B switches 
to the first channel and broadcasts a channel activity query 

5 CAQ to nodes within 1-hop of node 2B (FIG. 16). Nodes lA, 2A 
and 3A send channel activity replies CAR to node 2B with 
information on the link performance of the first channel (FIG. 
17). If the bandwidth on the first channel is acceptable to 
• node 2B, it will return to the second channel and broadcast a 

10 channel change message to inform any nodes IB, 3&, 4B and 5B 
that it is changing to the first channel. These nodes would 
then note where node 2B can be found for future reference. If 
the bandwidth is not acceptable, node 2B will move to a third 
channel and repeat the steps. If all channels have been 

15 visited and node 2B has not found bandwidth above the QoS 
threshold, then it will select the best one, and may 
periodically search for a better channel. 

A system aspect of this embodiment of the present 
invention is directed to the mobile ad hoc network 26 having a 

20 plurality of mobile nodes 30, and a plurality of wireless 
communication links 32 connecting the plurality of mobile 
nodes together over a plurality of channels- Referring to 
FIGs. 6 and 7, each mobile node comprises a router 40 having a 
communications device 42 to wirelessly and unidirectionally or 

25 bi-directionally communicate with other nodes via the wireless 
communication links 32, and a controller 40 to route 
communications via the communications device. The controller 
40 includes a link performance monitor 80 to monitor link 
performance on a first channel. A channel scouting unit 82 

30 scouts one or more other available channels when the monitored 
link performance on the first channel falls below the QoS 
threshold. 
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The channel scouting unit 82 switches to a second 
channel, broadcasts a channel activity query to determine the 
link performance for the second channel, and processes replies 
to the channel activity query to. determine the link 
5 performance for the second channel. Also, the channel scouting 
unit 82 switches back to the first charmel and broadcasts a . 
channel change message if the link performance on the second 
channel is above the QoS threshold, or switches to subsequent 
channels and broadcasts channel activity queries to determine 

10 the link performance for those channels if the link 
performance on the previous channel is below the QoS 
threshold. Alternatively, the channel scouting unit 82 may 
switch to another channel and passively monitor the link 
performance for the second channel • A link performance 

15 information memory 66 stores the link performance information 
of each of the plurality of channels, and a channel 
information memory 68 stores channel information for 
neighboring nodes. 
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THAT VmXCn IS CIAXMED IS: 



1. A method for determining a route from a source 
node to a destination node in a mobile ad hoc network 
5 comprising a plurality of intermediate mobile nodes between 
the source node and the destination node, the method 
comprising: 

at the source node, transmitting a quaiity-^of- 
service (QoS) route request to discover routing to the 
10 destination node based upon a QoS parameter, the route request 
including a flow identifier and a QoS link metric; 

at each intermediate node, determining whether the 
intermediate node can support the requested QoS parameter of 
the QoS route request and, if so, updating the QoS link, 
15 metric, forwarding the QoS route request to one of other 

intermediate nodes and the destination node, and ten^orarily 
reserving node resources for QoS route requests having 
supportable QoS parameters; 

at the destination node, upon receiving the QoS 
20 route request/ generating a reply to the source node including 
the flow identifier and updated QoS link metric for each 
discovered route; 

at the source node, generating QoS route metrics 
based upon updated QoS link metrics in replies from the 
25 destination node for discovered routes; 

at the source node selecting a route to the 
destination node based upon the QoS route metrics; and 

at the source node transmitting route confijcmations 
to intermediate nodes on the selected route. 

30 

2. A method according to Claim 1 wherein the QoS 
parameter is based upon at least one of available bandwidth, 
error rate, end-to-end delay, end-to-end delay variation, hop 
count/ expected path durability, and priority. 
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3- A method according to Claim 1 further 
comprising, at the intermediate nodes and the destination 
node, detecting whether the node can continue to support the 
requested QoS parameter of the QoS route request and, if not, 
5 generating a QoS error notification to the source node. 



4 . A method according to Claim 3 further 
comprising, at the source node, maintaining the selected 
route, upon receiving the QoS error notification, while 
transmitting a second quality-of -service (QoS) route request 
to discover new routing to the destination node based upon the 
QoS parameter. 



5. A method according to Claim 3 further 

15 comprising: 

at the source node, selecting a standby route; 
at the source node, switching to the standby route 
upon receiving the QoS error notification. 



20 6. A mobile ad hoc network comprising: 

a plurality of mobile nodes; and 
a plurality of wireless communication links 
connecting the plurality of mobile nodes together; 
each mobile node comprising 
25 a communications device to wirelessly 

communicate with other nodes of the plurality of 
nodes via the wireless commxini cation links, and 

a controller to route communications via the 
communications device, and comprising: 

a route discovery unit to transmit 
quality-of-service (QoS) route requests 
to other nodes to discover routing to a 
destination node based upon at least one 
QoS parameter, the route request 
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incluciing a flow identifier and a QoS 
link metric, 

a route request processing unit to 
determine whether the node can support a 
5 requested QoS parameter of a QoS route 

request and to update the QoS link 
metric, 

' - a temporary resource reservation 

table containing temporary node resource 
10 reservations for QoS route requests 

having supportable QoS parameters, 

a route metric formation unit to 
generate QoS route metrics based upon 
updated QoS link metrics in replies from 
15 nodes with node resource reservations, 

and 

a route selection unit to select a 
route to the destination node based upon 
the QoS route metrics and to transmit 
20 route confirmations to nodes on a 

selected route. 



7. A network according to Claim 6 wherein the QoS 
parameter is based upon at least one of available bandwidth, 

25 error rate, end-to-end delay, end-to-end delay variation, hop 
count, expected path durability, and priority, 

8. A network according to Claim 6 wherein the 
route selection unit selects at least one standby route 

30 without sending confirmations to the nodes on the standby 
route . 
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9. A network according to Claim 6 wherein the 
route selection unit selects at least one standby route and 
sends confirmations to the nodes on the standby route. 

10. A network according to Claim 6 wherein the 
route request processing unit detects whether the node can 
continue to support the requested QoS parameter of the QoS 
route request and/ if not, generates a QoS error notification. 



-33- 



wo 03/093926 



PCT/US03/13141 



1/13 




FIG. 2. 



03/093926 



2/13 



PCT/US03/13141 




wo 03/093926 



PCT/US03/13141 



3/13 




106 



124 



SOURCE NODE i 
SWITCHBTO 1 
STANDBY ROUTE I 



UPDATE QqS UNK, 
FORWARD RREQQ, 
TEMP REZ RESOURCE 



—108 



DESTINATION NODE 
GENERATE REPDT 
RRgQ 



SOURCE NODE 
GENERATES QnS 
ROUTE METRIC 
i 



SOURCE NODE 
SEIECTS ROUTE 



110 



112 



-114 



FIG 5. 



I — 



"1 



SOURCE NODE 
SEIECTS STANDBY k.i22 



SOURCE NODE 
TRANSMITS 
. CONFQ 



SEND QqS BROR 




-116 



wo 03/093926 



PCT/US03/13141 



4/J3 



Tx/Rx 




MICROCONTROUe 


42^ 


/ ^44 



40. 




46 . 



J 



FIG. 6. 




80 86'-' 



FIG J. 



wo 03/093926 



PCTAJS03/13141 



S/13 




HG.9. 



wo 03/093926 



PCTAJS03/13141 



6/13 




FIG. 10. 



wo 03/093926 



PCTAJS03/13141 



7/13 

200 



C START 




iz: 



I . Quay MODES i.^'-204 
iFOR.QnS METRIC [ 

I . I 

1 VERIFY OTHER i-"- 206 
I NODES REPUED j 

L i 



CALCUIATE 
QqS TAG VALUE 



-208 



I CAUCROUTE& 
I CONNEaiVITY 
i INFO 



210 



TRANSMIT i/'-212 



ROIfTE&CONNeCTi 
INFO . j 



REPIYTO L^214 
RREQQ INDICATE 
ADMIT OR NOT 



FIG. 11 



216 



wo 03/093926 



PCT/US03/13141 



8/13 



3oa 



TRANSMIT 
RREQQ 



CAUCUIATE 
QqS TAG VALUE 



DETBiMINE 
ADMISSION 
OFTRAFHC 



REPOT TO 
RREQQ INDICATE 
ADMISSION 



POOCING 
ADMITTH) 
TRAffIC 



PREVBfrPROR 
OF EXCESS 
TRAFHC 



-302 



-304 



306 



308 



-310 



-312 



CSTOP 



314 



FIG. 12. 



wo 03/093926 



PCT/US03/13141 




RG.13. 



wo 03/093926 



PCT/US03/13141 



10/13 



MONITOR 
TRAFFIC. 



.400 

^402 



GENERATE 
TRAfflCINFO 



-404 



.406 



STORETRAFRC 
INFO IN 
■ BUFFER 

izxz: 

I GENERATE . | ..408 
i TRAFHC DEST.. K 
I ■ I NFO j 

f" "i 
i STORETRAFRC r" 
I. ..DEST.INFO { 



.-410 



I 

1 . 



I . SElfa ROUTE 
I DISCOVERY 



PROTOCOL 1 



DSCOVBl 
TRAFRC 
ROUTES 



SElfa ROUTE 
FROMDSCOVED 
TRARC ROUTES . 

/"-;^:^^^4l8 

c STOP, 

H6.14. 



.414 



416 



wo 03/093926 



PCTAJS03A13J41 



.11/13 




HG.16. 



wo 03/093926 



PCT/US03/13141 



12/13 




nG;17. 



wo 03/093926 



PCT/US03/13141 



13/13 



512-^ SWJTCH 
1 CHANNBS 



PASSIVE 
MONirOR 



OR 



514'"' 



BROADCAST! 
QUERIES I 

516 -:„I._„_ 

PROCBS 
REPUES 

1 

518"' 




(START > ^ 



500 



MONITOR UNK 
PERFORMANCE 
ONISTCHANNa 



SCOUHNG 
OTHER 

CHANNELS 



BROADCAST 
CHANNR CHANGE 
MESSAGE 



STORING UNK 
PDIFORMANCE 

INFO 



STORING CHANNE 
INFO FOR OTHER 
NdDES 



:502 



-504 



506 



-508 



510 



520 



RG.IB. 



(12) INTERNATIONAL APPUCATION PUBUSU£D UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World InteUectua] Property 
Organization 
International Bureau 

(43) International Publication Date 

13 November 2003 (13.11.2003) 




(10) International Publication Number 

PCT WO 2003/093926 A3 



H04L 12/26 



(51) Intemalianal Patent ClassiOcatioa^: 

(21) iDlemationol Application Number: 

PCTAJS2003/013141 

(22) IntemaUonal Filing Date: 28 April 2003 (28.04.20O3) 

(25) Filing Language: ^ English 

(26) Publication Language: English 

(30) Priority Data: 

10/134JIS 29 April 2002 (29.04.2002) US 

(71) Applicant: HARRIS CORPORATION [USAJS]; 102S 
W. Nasa Blvd., Melbourne. FL 32919 (US). 

(72) Inventors: BILLUARTZ, Tom; 23SS Polonius Lane« 
Melbourne. FL 32934 (US). CAIN, Joseph, Bibb; 200 
Melbourne Avenue. Indialantic, FL 32903 (US). 

(74) Agents: YATSKO, Michael, S. el ul.; Harris Coiporation, 
1025 W. Na.sa Blvd. Melbourne, 32919 (US). 



(81) Designated States (national): AE. AG, AL, AM. AT, AU, 
AZ. BA, BB. BO, BR. BY. BZ. CA. CH, CN, CO, CR, CU, 
CZ, DE, DK, DM, DZ. EC. EE, ES, B. GB, GD, GE, GH. 
GM. HR. HU. ID, IL. IN. IS. JP. KE, KG, KP, KR, KZ, LC. 
LK. LR, LS, LT. LU, LV. MA, MD. MG. MK, MN, MW. 
MX. MZ. NO. NZ. CM. PII, PL, FT. RO. RU, SD. SE. SG. 
SK. SL. TJ. TM, TN, TR, TT, TZ, UA, UG. UZ. VN. YU, 
ZA. ZM. ZW. 

(84) Designated States {regional): ARIPO patent (GH, GM. 
ICE. 1-S. MW. MZ. SD, SL. SZ. TZ, UG. ZM, ZW). 
Eurasian patent (AM. AZ, BY, KG, KZ, MD, RU, TJ, TM), 
European patent (AT. BE. BG, CH, CY, CZ, DE. DK. EE, 
ES, n, FR. GB. GR. HU. IE, FT. LU, MC. NL. PT. RO, 
SE. St, SK, TR). OAPI patent (BF. BJ, CF. CG. CI. CM, 
GA. GN. GQ, GW, ML, MR, NE, SN. TD, TG). 

Published: 

— with international search report 

[Continued on next page J 



(54) TJUc: QUALITY OF SERVICE ROUTING FOR MOBILE AD HOC NETWORKS 



< 
On 

I 

o 

o 




(57) Abstract: The method includes 
transmitting a Quality-of-Service {QoS) route 
request (102) to discover routing based upon 
a QoS parameter, and the route request (102) 
including a flow identifier and a QoS link 
nietric. Furthermore, the method includes 
each intermediate node determining whether 
the node can support the requested QoS 
parameter (104), and if so, updating the QoS 
link metric, forwarding the QoS route request, 
and temporarily reserving node resources (108). 
The destination node, upon receiving the C^S 
route request, generates a reply (110) including 
the flow identifler and updated QoS link metric 
for each discovered route, and the source node 
generates (^ route metrics (112) based upon 
updated QqS link metrics in the replies. The 
source nodes selects a route to the destination 
node (1 14) based upon the QoS route metrics, 
and transmits route confirmation to iniennediate 
nodes on the selected route (116). 



wo 2003/093926 A3 illlDBiliiniDimiiillllllii 



(88) Date or publication of the Internationa] search report: 

12 February 2004 

For two-ietier codes and other abbreviarions, refer to ihe "Guid- 
ance Notes on Codes and Abbreviations" appearing at the begin* 
ning ofetsdx regular issue oftlte PCT Gazette, 



INTERNATIONAL SEARCH REPORT 



Internatioiial application No. 
PCT/US03/13141 



A. CLASSIFICATION OF SUBJECT MATTER 
IPCC7) : H04L 12/26 

US CL : 370/228,23 1 ,252,400; 455/445; 709/239 
Acconiing to IntemariODal Pateni Ctassiftcation (IPC) or to both national classification and IPC 

B. FIELDS SEARCHED 

Minimum documentation searched (classification system followed by ciasslficadon symbols) 
U.S. : Please See Continuation Sheet 



Documentation searched other than minimum documentation to the extent that such documents aie included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 
Please See Continuation Sheet 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category ♦ 


Citation of document, with indication, where appropriate, of the relevant passages 


Relevant to claim No. 


Y 


US 6,154,444 A (MASUO et al.) 28 November 2O00, figure 2 and abstract. 


1-10 


Y 


US 6,262,976 Bl (MCNAMARA) 17 July 2001, abstract and figure 5. 


MO 


Y 


US 5,995,503 A (CRAWLEY et al.) 30 November 1999. abstract and figures 1-3. 


MO 


Y 


US 6,377,551 Bl (LUG et al.) 23 April 2002. figure 1 and abstract. 


MO 


Y 


US 6,256,300 Bl (AHMED et al.) 03 July 2001, abstract and figures 6a and 6b. 


MO 



I I Further documents are listed in the oontimiatioa of Box C. I I See patent family annex. 



* Special catesoties of dted doctwncnn; 

"A** docunmt defining (hs general state of the ait wtiich U not consUered to be 
of panlcular relevance 

"E* earlier ajjpUcaiion or paxem published on or afker (he intcfnational fUins date 



lattr dofaimrm published after the tntemational filiiQ date or piioiiQ^ 
date and cot in conAla with the applieaiion but dted to underRand die 
principle or theory trndertytog the Invention 



t whkh may duow doubts on piioriQr daiiiKa) or wtdch b dnd to 
establidi the pubHcadoo date of another cUadon or other special reason (as 
specified) 

"O" documeiu reffentog lo an oral disclosure, use, exhlbliUm or other means 

"p" afff^t1flt^nl pitti iifttwii prior to the international filing date but later than (be 
priority date cisdmed 



documeiit of poidcular idevanoe; iho claimed 
cnnslditicd novel or canm be considCRd to 
vAien the doGuneoi is taken alone 



cannot be 
an inventive step 



documem of particular relevance; ihs claimed tnvemioa cannot be 
considered to Involve an inventive step when the Annrnt^i is 
ootnblned wldi one or more other such dpcvini^n^Ki such ^x*mb ^™^fff n 
being obvious co a person tklUed In tbe an 

document mrmbcir of tbe same paxenl £BniiIy 



Date of the actual completion of the international search 
14 November 2003 (14.11.2003)' 


Date of mailing of the international search report 


Name and mailing address of the ISA/US 
Mail Stop per. Ata: BAA/S 

P.O. Box 1450 

Alexandria, Virginia 22313-1450 
Facsimile No. a03)305-3230 


Authorized officer 

Telephone No. (703)305-3900 



Fom PCT/ISA/210 (second sheet) Qvly 1998) 



INTERNATIONAL SEARCH REPORT 



PCTA;S03/13141 



Continuation of B. FIELDS SEARCHED Item 1: 

370/228,231,252,400; 455/445; 709/239 370/225.228,229.231.235,236,238.252,254,255,331,349,351,389,392,293,400,401; 
455/422,432.433,436,437.445,517; 709/232,234.235,238.239 



Contimiation of B. FIELDS SEARCHED Item 3: 
USPAT 

routing, ad hoc, nodes, QoS 



Fbnn PCT/I5Ay210 (second sheet) (July 1998) 



